home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2000 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  7.0 KB
  1. Path: news.mindlink.net!news
  2. From: brent_bysouth@mindlink.bc.ca (Brent Bysouth)
  3. Newsgroups: comp.lang.c++,comp.lang.pascal.delphi.misc
  4. Subject: Re: C++ with Zapp vs. Delphi
  5. Date: Mon, 15 Jan 1996 13:10:14 GMT
  6. Organization: MIND LINK! - British Columbia, Canada
  7. Message-ID: <4ddke3$5lf@fountain.mindlink.net>
  8. References: <4coar6$d4n@sun4.bham.ac.uk> <4coip7$69s@news1.usa.pipeline.com> <fRA+w0JfFG5X089yn@oslonett.no> <4dcc4d$6anc@tigger.cc.uic.edu>
  9. NNTP-Posting-Host: line005.nwm.mindlink.net
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. olczyk@sunphy1 (Thadeus Olczyk) wrote:
  13.  
  14. Oh well, I'm probably falling for the bait here...
  15.  
  16. >Rune Moberg (mobergru@oslonett.no) wrote:
  17. >: Yes, comparing VC++ to Delphi is indeed possible. I'm not sure of VC++'s
  18. >: code optimizations, but generally Delphi would loose out to a C++ compiler,
  19. >: because C++ compilers tend to make more use of registers and optimizes
  20. >: loops better. This will change in Delphi 2.0, where Delphi shares compiler
  21. >: backend with BC++ 5.0.
  22.  
  23. >As long as Delphi supports the toxic combination static typing and 
  24. >single inheritance , people will not be able to use polymorphism
  25. >to replace case statements which will always make Delphi slower in any
  26. >large application. 
  27.  
  28. You don't seem to understand the significance of RTTI in Delphi.  You
  29. can execute methods and set/get properties by name lookup -- ie.
  30. dynamic method resolution similar to what's in ObjectiveC & Smalltalk.
  31. Delphi's VCL makes extensive use of this when components are streamed
  32. in from form files.  Also, through the use of virtual constructors and
  33. class references (ie. metaclasses), you can write generic code that
  34. constructs objects of unknown subtypes.  I've personally used these
  35. things to implement a pseudo-late binding class "factory" that you can
  36. load from DLLs.
  37.  
  38. Because of these things, case statements certainly aren't the norm in
  39. Delphi programming.
  40.  
  41. >: Now, let's compare RAD, ease of maintenance and readable code. Categories
  42. >: where Delphi has a head start...
  43.  
  44. >Let's. RAD has recently come into disfavor in publications like JOOP, Object,
  45. >and even Byte. Last summer InfoWorld reported a growing disillusionment
  46. >of MIS departments with RAD tools. It seems that when RAD is introduced
  47. >the parts of a project that got finished before RAD was introduced got finished
  48. >faster, but that projects as a whole showed the same cost and failure rate 
  49. >before and after.
  50.  
  51. Given many of Delphi's RAD competitors, I can see why RAD has a bad
  52. name.  Delphi is popular because it is a 'second-generation' RAD tool,
  53. and eliminates many of the problems of first generation RAD tools.
  54.  
  55. >I would like to see how you justify a claim of ease of mainenance when Delphi 
  56. >does not support MI. Implication-- under some circumstances one cannot abstract
  57. >out common behavior and therefor must cut and paste code-- ie-- they must copy bugs.
  58. >Everyone I know agrees that that causes a maintenace nightmare.
  59.  
  60. Yes, I agree that cutting & pasting code brings on maintenance
  61. nightmare.  I'm less sure that a lack of MI does though, as would many
  62. others.  MI vs. SI is an age old argument, and you're not going to get
  63. a concensus on it anytime soon.  If you really want a discussion on
  64. it, start a thread in comp.object!
  65.  
  66. [...]
  67.  
  68. >: >Maybe C vs. Pascal , but C++ is OO and Object Pascal is a fraud perpetuated by 
  69. >: >Borland on the world.
  70.  
  71. Would you care to elaborate on this one?  If you're attempting to say
  72. that C++ is more OO than Object Pascal, could you back this up?
  73.  
  74. >No MI isn't required for OO. Smalltalk  does well without it, but then 
  75. >again Smalltalk is dynamically typed. For a statically typed language
  76. >MI is almost essential. You do know that Delphi is a statically typed
  77. >language? Didn't you read the part of my post where I  noted this? You 
  78. >can read can't you?
  79.  
  80. Refer to my previous statement concerning RTTI. 
  81.  
  82. >If MI is not so great why does Borland simulate it in the VCL? Did you notice
  83. >that I pointed this out? You can read can't you?
  84.  
  85. I think all of us noticed you saying that. Please support it though --
  86. give examples of where Borland simulated MI in the VCL.  However,
  87. don't confuse MI with delegation (which at least Object Pascal and
  88. Objective C support and encourage) and association (do any mainstream
  89. languages support this as a language feature?).  
  90.  
  91.  
  92. >: I'd go so far to claim that Object Pascal is more OO than C++. Hey, Delphi
  93. >: has even got properties, far more useful than any missing C++ feature!
  94.  
  95. >I notice that you didn't answer a charge I made about Delphi.
  96. >Since when is language where the following happens:
  97.  
  98. >a method that is declared as generally accessible is not accessible
  99. >under many circustances without violating a fundamental rule of
  100. >OO  or do severe workaround,
  101.  
  102. >considered an OO language. 
  103.  
  104. >You did read the part where I mentioned this? You can read can't you?
  105.  
  106. Again, I think everybody read this. What exactly are you talking
  107. about? Public methods are public.  Published methods are published.
  108. Are you commenting on unit level access to protected and private
  109. variables (ever heard of friends in C++?) ? Please clarify...
  110.  
  111. >Add to the other weaknesses of Delphi the fact that you can instantiate 
  112. >abstract classes. How good is a language which allows you to make a
  113. >contract and then break it.
  114.  
  115. I've often wondered myself why you can instantiate abstract classes.
  116. However, if you're coming from a C++ background, I think it's a bit
  117. hypocritical to make the second statement that you did.  Why not talk
  118. about C++'s problems wrt its VMT? Ie.
  119.  
  120. - C++ objects are not binary compatible across compiler
  121. implementations
  122.  
  123. - changes in C++ objects that affect the VMT mean that code accessing
  124. that object must be recompiled (can this be classified as a
  125. "maintenance nightmare"?).  This is probably C++ worst problem -- it
  126. gets to the point where DLLs compiled from C are more reliable and
  127. reusable than those from C++.
  128.  
  129. BTW, Delphi has a VMT but also supports a dynamic method table that
  130. gets around this problem (ie: methods declared with the dynamic and
  131. message directives).
  132.  
  133. >As for properties I would like to see a justification for why properties
  134. >are so great. They are not a bad thing, but I don't see where they are
  135. >so great as to be considered a critical feature of a language.
  136. >I would like to see some argement for why properties are considered a better
  137. >feature then a set of conainer classes.
  138.  
  139. I classify properties as a nice-to-have (but non-essential) feature.
  140. I classify MI as the same -- Object Pascal & Smalltalk surely seem to
  141. get by alright without them.  (Or at least you haven't proven
  142. otherwise).
  143.  
  144. And yes, if you want container classes, you can construct them using
  145. Delphi's RTTI and class objects.  They wouldn't be a compiler-known
  146. entity (ie. they wouldn't have full static typechecking), but you
  147. certainly can do them.
  148.  
  149. ---
  150.  
  151. Alas, after having said all this, I'm not sure that you're interested
  152. more in discussion or in flaming.  Your response to Rune seems to
  153. indicate the latter.
  154.  
  155.  
  156. --------------------------------------------------
  157. brent_bysouth@mindlink.bc.ca
  158. VB, Delphi & SQL Development
  159. Vancouver, BC.
  160. (604) 689-2616
  161. -------------------------------------------------
  162.  
  163.